It is common practice in many industries to provide a backup data storage entity. In critical applications and industries, host entities often have multiple data storage entities coupled through a controller to a computer and operated in a mirrored (also known as shadowed) configuration. In a mirrored configuration, data storage entities are treated as pairs, and all data intended for a particular data storage device is duplicated on a block-for-block basis on the paired “mirrored” data storage entity. Mirroring can be accomplished by special circuitry or by computer program control, or a combination thereof.
One type of mirroring architecture is asynchronous mirroring. Using asynchronous mirroring, once a write command (hereafter referred to as a “write”) is received at a primary storage entity, a completion acknowledgment is sent directly back to an originating host entity to indicate that a subsequent write may be sent. However, this acknowledgment may not necessarily indicate that the write was received at (or even yet transmitted to) a remote storage entity. Instead, if the write is placed in the buffer of the primary storage entity, then the write is issued a sequence number indicating its position in relation to the other writes stored in the buffer. Subsequently, the write can be forwarded to the remote storage entity.
Another type of mirroring is synchronous mirroring. In contrast to asynchronous mirroring, a synchronous mirror primary storage entity delays sending acknowledgement (of having completed a write from the host entity) until the primary storage entity has received acknowledgement that the secondary storage entity has completed the write (that the primary storage entity had forwarded). Relative to asynchronous mirroring, synchronous mirroring delays the host from sending a second write until two storage entities (instead of merely one) in the chain have actually received a first write.
FIG. 6 illustrates a redundant data storage arrangement 900 according to the Background Art. Arrangement 900 includes a host 905 that can send writes to a primary storage entity 910 (hereafter, primary storage 910), which is configured to mirror the data originating on host 905. Also included in arrangement 900 are a first remote storage entity 920 (hereafter first remote storage 920) and a second remote storage entity 930 (hereafter, second remote storage 930) located significantly farther away from host 905 than is first remote storage 920. Typically, primary storage 910 synchronously forwards writes to first remote storage 920 and asynchronously forwards writes to second remote storage 930. As such, primary storage 910 and first remote storage 920 together operate as synchronous mirrors of the data originating on host 905.
Due to differences in distances from primary storage 910, and differences in communication path media and synchronous versus asynchronous communication considerations (asynchronous being opportunistic in terms of forwarding writes), second remote storage 930 typically is not write current relative to first remote storage 920. In other words, typically, first remote storage 920 has received forwarded writes that have not yet been forwarded to second remote storage 930.
If primary storage 910 were to fail, first remote storage 920 would take over the role previously fulfilled by primary storage 910. But before first remote storage 920 could begin forwarding, asynchronously, writes to second remote storage 930, it would be necessary to make second remote storage 930 write-current. First remote storage 920 does not know how far behind second remote storage 930 is in terms of write-currency. As a result, an out-of-order (OOO) full copy of the data on first remote storage 920 must be made to second remote storage 930, which can take a long time depending upon the distance and communication media. Plus, during (or, in other words, before the completion of) the full copy, the application program resident on host 905 (or its clustered host local to 920) is vulnerable to first remote storage 920 failing, which would leave no usable data on second remote storage 930 because an OOO full data only yields usable data upon completion.